Saving Redundant Messages in BnB-ADOPT

We have found that some messages of BnB-ADOPT are redundant. Removing most of those redundant messages we obtain BnB-ADOPT, which achieves the optimal solution and terminates. In practice, BnBADOPT causes substantial reductions on communication costs with respect to the original algorithm. BnB-ADOPT (Yeoh, Felner, and Koenig 2008) is a reference algorithm for distributed constraint optimization (DCOP), defined as follows. There is a finite number of agents, each holding one variable that can take values from a finite and discrete domain, related by binary cost functions. The cost of a variable assigning a value is the sum of cost functions evaluated on that assignment. The goal is to find a complete assignment of minimum cost by message passing (for details on DCOP definition see (Modi et al. 2005)). BnB-ADOPT is a depth-first version of ADOPT (Modi et al. 2005), showing a better performance. As ADOPT, it arranges agents in a DFS tree. BnB-ADOPT messages are VALUE(i, j, val, th), –i informs child or pseudochild j that it has taken value val with threshold th–, COST(k, j, context, lb, ub) –k informs parent j that with context its bound are lb and ub–, and TERMINATE(i, j). –i informs child j that i terminates–. A BnB-ADOPT agent executes the following loop: it reads and processes all incoming messages, and takes value. Then, it sends the following messages: a VALUE per child, a VALUE per pseudochild and a COST to its parent. BnB-ADOPT contexts can be updated by VALUEs or COSTs, while in ADOPT contexts are updated by VALUEs only. This is due to timestamps that go with individual values allowing to determine which is more recent (timestamps are called counters referred as ID in (Yeoh, Felner, and Koenig 2008)). Here, we assume that the reader has some familiarity with BnB-ADOPT code. We show that some BnB-ADOPT messages are redundant. Removing most of those redundant messages we obtain BnB-ADOPT, keeping optimality and termination. BnB-ADOPT causes substantial reductions on communication costs, dividing by a factor from 2 to 6 the number of messages (experimental testing on several benchmarks). ∗Partially supported by Spanish proj. TIN2009-13591-C02-02. Copyright c © 2010, Association for the Advancement of Artificial Intelligence (www.aaai.org). All rights reserved. Redundant Messages In the following i, j and k are agents executing BnBADOPT. Agent i, holding variable xi, takes value v when the assignment xi ← v is made and i informs of it to its neighbors. The state of i is defined by (1) its value, (2) its context (values of agents located before i in its branch, timestamps are not part of the context), and (3) for each possible value v and each j ∈ children(i), the lower and upper bounds lb(v, j)/ub(v, j). A message msg sent from i to j is redundant if at some future time t, the collective effect of other messages arriving j between msg and t would cause the same effect, so msg could have been avoided. Lemma 1 If i takes value v1 with timestamp t1, and the next value it takes is v2 (possibly equal to v1) with timestamp t2, there is no message with timestamp t for i st. t1 < t < t2. Proof. No VALUE is sent from i with timestamp bewteen t1 and t2: v1 and v2 are consecutive. COSTs build their contexts from VALUEs: no VALUE includes a timestamp between t1 and t2, so no COST will contain it for i. 2 Theorem 1 If i sends to j two consecutive VALUEs with the same val, the second message is redundant. Proof. Let V1 and V2 be two consecutive VALUEs sent from i to j with the same value val with timestaps t1 and t2, t1 < t2. When V1 reaches j, it may happen: 1. V1 does not update contextj [i]. When V2 arrives: (a) V2 does not update contextj [i]. Future messages will be processed as if V2 would have not been received, so V2 is redundant. (b) V2 updates contextj [i] which has timestamp t. Either (i) t2 > t > t1 or (ii) t2 > t = t1; (i) is impossible because Lemma 1; (ii) since t = t1 the value in V2 is already in contextj [i]. Every future message accepted with timestamp t2 of contextj [i] would also be accepted if timestamp were t1. Since Lemma 1, V2 is redundant. 2. V1 updates contextj [i] ← val, timestamp t1. When V2 arrives: (a) V2 does not update contextj [i]: as case (1.a). (b) V2 updates contextj [i]: since V1 updated contextj and Lemma 1, the timestamp of contextj [i] must be t1. Updating with V2 does not change contextj [i] but its timestamp is put to t2. Since there are no messages with timestamp between t1 and t2 (Lemma 1), any future message that could update contextj with t2 would also update it with t1. So V2 is redundant. 2